Oh boy Domain Driven Design is pretty nifty! I’ve been reading the “Implementing Domain Driven Design” book by Vaughn Vernon and I feel as those I've had a watershed moment in my knowledge of software architecture. So much of software design is about knowing where to create boundaries in the code, how to communicate across those boundaries and executing consistent logic within the boundaries. Needless to say, I think DDD is a really useful set of guidelines on how to do that in a complex domain while emphasizing that boundaries should be a reflection of the business.

DDD and Microservices

From my perspective, the ideas of DDD and Microservices seem to really complement each other and I'm surprised that they aren't in the same conversation more often.

In this talk, Mastering Chaos - A Netflix Guide to Microservices, the presenter Josh Evans agrees that microservices are "context bound and have data ownership", which to me dovetails very well with the concept of a "bounded context" in DDD. Even the originator of DDD, Eric Evans, discuss how Microservices are useful for implementing DDD in this talk: Microservices: At Last, Some Boundaries!

Miscellaneous DDD Musings

Ideas I really like:

• Expressing operations in the vocabulary of the ubiquitous language

• Operations to mutate entities go through the aggregate root

• Communicating across aggregates via domain events

I think DDD can be a double edge sword though. Though its guidelines, patterns and vocabulary are useful tools, DDD is itself complex and introduces new jargon. I really like this blog post, Tackling Complexity in the Heart of DDD, which tries to cut down on that complexity by separating the higher-level domain separation techniques from the tactical modelling techniques.